Problems cannot be solved with the same mindset that created them.
– Albert Einstein
In virtually any discipline, pursuit, or profession, there is a consistent desire to learn, advance, and to simplify. For systems engineering, it is no different. The breadth of systems engineering is vast, holistic in perspective and spans the entire lifecycle. It is often framed generically to ease its application to the challenge at hand – whether that be a next generation aircraft, a deep space mission, an automobile, a medical device, or a healthcare enterprise. But even this generic framing and description adds perceived complexity as we speak in abstract language with abstract context.
As complexity continues to grow – in the challenges we face; in the products, services, and enterprises that we engineer; in the environments in which we operate and in which we deploy our systems – there is a renewed push for simplification and simplicity in systems engineering. “We cannot solve complexity with complexity” is the mantra. After all, we need to accelerate the application and increase the breadth of understanding, and simplicity aids both.
But not all simplicity is helpful. Sometimes, in our pursuit of simplicity, we lose key concepts and ideas, damaging the application of systems engineering rather than easing and accelerating it. Simplification of any given topic or any given method can be done poorly with a loss in fidelity, but there are some areas where we should pursue simplicity and some that are bound for trouble.
As we advance the practice of systems engineering, where should we pursue simplicity?
Explaining Systems Engineering and Advocating Its Value to non-Systems Engineers. The old joke about engineers is, “Ask an engineer what time it is, and he will tell you how the watch works.” As in most cases, this exaggeration has its foundation in truth. Engineers are technical and trained to be detail-oriented. More than that, we are interested in and passionate about what we do. Unfortunately, this technical language, detail-orientation, and passion often spill over when we talk about systems engineering with non-systems engineers. Rather than explaining the key principles and corresponding value in simple, clear language, we use technical terms and go into great depth.
I once heard Dave Walden of Sysnovation share the following advice on briefing senior management: “Be bright – give them the critical information that they need structured logically so that your message comes across. Be brief – their time is valuable so tell them what you need to tell them and then stop talking; if they have a question they will ask. Then be gone.” When we talk about the systems approach that we bring and the systems we engineer, we should follow Dave’s advice, focusing on the key aspects of systems engineering and the value it brings in the language of the person we are talking to. If they want to know more, they will ask. Otherwise, we bury them with unnecessary detail and create the appearance of complexity rather than convey the critical essence and the unique value of what we bring.
Applying Systems Principles with non-Systems Engineers (or with Systems Engineers in Other Domains). Recently, as I taught a tutorial on the application of model-based systems engineering, an attendee raised the challenges he faces in his workplace. When working with domain experts and customers, he struggles to apply the “formality of systems engineering.” He would begin to explain processes and approaches – “requirements elicitation,” “allocation,” and more. Their eyes simply glazed over. He continued to explain that to be successful he had to leave behind the language of systems engineering and work with them in their terminology in order to be successful.
This conclusion isn’t surprising, but unfortunately the error is one made over and over again. Whereas systems principles are universal, the language used to describe them is not. The systems engineer knows that she is the technical glue that connects the members of the engineering team and the translator that helps map various concepts and concerns across the project. We have to live that translation concept at all times, seamlessly mapping to the language of the domain, stakeholder, or specialist. Sometimes simplicity comes not from the fundamental concept but simply the way we choose to language it. “Requirement” may not be universally understood, but all projects have needs or things that we are trying to satisfy. We need to bring the right degree of technical rigor to the problem at hand, and in doing so we must bring the concept and method in the language of those with whom we are working.
Tailoring Systems Engineering Processes. Systems engineering processes and standards are meant to be tailored for a specific problem and application. Developing a deep space probe, a next-generation medical device, and an app to hail a ride-sharing service are different. If we apply the same processes and standards to all, we will either fail to address key concerns or crush a problem through a heavy-handed, bureaucratic approach. There are good and bad ways to tailor – simply eliminating a process in the name of simplicity without defensible rationale is not appropriate simplification. Ideally, our organizations will pre-tailor the primary processes and methods to the problem archetype we typically handle. Tailoring is essential, and tailoring is best done by senior practitioners with expertise in the application area.
Communicating System Concerns to Connect and Align the Project Team. The scope of systems engineering is immense, even for a given project. While the holistic perspective and understanding the interconnections and interactions is essential to system success, it is not necessary to expose the full scope, depth, and complexity to everyone at all times. We cannot deny scope and complexity and hope they go away, but we can use overlapping views and perspectives to communicate and analyze specific aspects of the problem.
When systems engineers serve as the technical connective tissue for a project, our objective is not to expose all details to all project members at all times. Instead, our job is to map and translate between systems concerns and the specific user, stakeholder, and specialist perspectives, simplifying what each individual sees so that collectively we can see the whole problem and develop the right solution. To truly communicate, we should simplify to the language, format, and notation that each individual understands, always mapping back to an integrated understanding. That may mean communicating in a cartoonish diagram for one individual and a technical schematic for another, simplifying specific views to enhance communication. By enabling a “your data, your way” mentality while providing the necessary connectivity, coherence, and integration necessary, we can bring necessary simplicity to communication and analysis without eliminating the required rigor to successfully deliver system success.
So where do the traps lie? Where are we tempted to find simplicity yet find problems and position for failure instead?
Breaking Systems Engineering into Stovepipes. Reductionist techniques have allowed us to focus on narrower and narrower concerns over the years, leading to very specific disciplines that have yielded great progress. It is therefore natural that when confronted with the broad scope of systems engineering that we would break it into stovepipes. But systems engineering is different as we focus on the critical interconnections and interactions. Breaking systems engineering up not only denies its fundamental holistic nature, but it also complicates systems engineering as we attempt to separate tightly coupled concerns.
The interpretation of the classic waterfall approach to systems engineering led many to treat requirements, logical design, physical architecture, and test as separate concepts that could largely be completed independently in series. Systems engineering was always intended as a concurrent approach, and that concurrent mentality is ever-more critical as the pace of change accelerates. Our environments raise new challenges, users identify requirements changes, and new implementation technologies become available. Attempting to decouple requirements makes impact analysis more complex and ignores the fact that many requirements are actually dependent upon the solution path chosen. Logical (functional) and physical architectures are very tightly coupled, and as we consider new implementations – even at an abstract level – we may change our functional architecture. Embracing the interconnected nature of our problem and approach actually creates resilience and accelerates application where attempts to decouple simply complicate the effort.
Adopting and Applying Processes in a Mechanistic Manner. Selecting and applying the right processes and standards for the chosen problem is a valuable enabler to project success. However, the purpose of systems engineering is not following a specific process. Nor is it complying with specific standards. The purpose of systems engineering is delivering the right business value to our customers, users, and stakeholders via the system of interest. Where processes and standards assist this journey, they serve as roadmaps and aids in the solution process. Unfortunately, processes are applied in the name of compliance without true understanding, leading to work performed in the name of performing work rather than producing the requisite value. Too often, standards are selected in the name of being standard-compliant rather than selecting those standards that truly apply to the specific situation. In both cases, the systems engineering effort becomes more complex and less successful as the systems engineers serve the processes and the standards rather than the processes and standards serving the engineering effort.
Narrowing and “Streamlining” the Underlying System Model. Systems engineering serves to align the broader team around a common understanding of the problem, leveraging diversity of perspective and breadth of capability to deliver the right solution. Systems engineering must fundamentally embrace both the full breadth of the problem and the interconnectedness of the problem, solution, and programmatic dimensions. Embracing this and seeing the big picture is system thinking. Attempting to simplify this is at best analytic thinking, at worst acting as an ostrich with its head in the sand.
If we are to truly understand the problem and craft a system solution, we must capture the full breadth and richness of problem and solution. This requires broad and rich concepts, both in the information we consider and the nuanced interrelationships. We must consider context, requirements, risks, behaviors, implementation, verification, validation, and more. We must carefully differentiate the many possible relationships between various concepts.
Of course, seeing and addressing this full breadth in its full richness at all times is virtually impossible. Today’s challenges are too large and too complex for any one person to manage in their mind. However, that does not mean that we ignore scope, detail, or semantic richness. Instead, we work the problem in layers of detail to always act informed by relevant context and work within a convergent design envelope. We apply the concept of separation of view and model, leveraging a diverse set of representations to construct, analyze, and communicate specific problem and solution aspects from particular perspectives to serve specific audiences and analytic needs. The path to success is not in simplification of the underlying mental model. The path to success is in using diverse yet consistent and coherent views from multiple perspectives to truly understand that complex, interrelated, and rich mental model.
Everything should be made as simple as possible, but not simpler.
– Albert Einstein
Simplification done well can become elegance. It is something that we should not only embrace but something for which we should strive. However, as H.L. Mencken warns us, “For every complex problem there is an answer that is clear, simple, and wrong.” Many of the approaches championed today to avoid “using complexity to solve complexity” ignore critical considerations and concerns and are at best naïve.
Simplification done wrong is not simplicity. Simplification done wrong is simplistic, and that is something that systems engineering and the solutions we deliver simply cannot afford.
